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I. INTRODUCTION 



Chapter I discusses the purpose and content of this thesis. It also provides a brief 
overview of the background and objectives of the research, questions answered, and the 
methodology used. 

A. BACKGROUND 

As the Department of Defense (DOD) and the Department of Transportation 
(DOT) are pushed to cut spending through downsizing and restructuring, the need to 
redesign existing military processes seems inevitable. Recent government initiatives 
provide strong incentives for federal agencies to improve the services they provide to the 
public, with greater accountability for achieving results quicker and at lower cost. The 
1993 Government Performance and Results Act establishes expectations for agencies to 
plan strategically and achieve better mission outcomes. The "Contract With America", 
with its inherent budget and personnel reductions, encourages federal agencies to find 
ways to work more efficiently and effectively. In addition, the Administration's National 
Performance Review requires that federal agencies establish customer service standards 
and focus efforts on improving the value of government services to the public. [A1 Gore, 
1993] 

In line with these initiatives, the Assistant Secretary of the Army for Financial 
Management (ASA-FM) announced in a Personnel Leader’s Meeting in Columbia, South 
Carolina on April 2, 1998 that she would use five broad categories as a framework to 
communicate a variety of initiatives. The ASA-FM notes that, “Maximizing information 
technology is critical to the success of DOD reengineering efforts.” [Helen T. McCoy, 
1998] To this end the Defense Finance and Accounting Service Indianapolis (DFAS-IN) 
is preparing to test and release a kiosk terminal and eventually a web based application 
that will allow service members to access their Leave and Earnings Statements (LES), 
change allotments, and even change their tax withholdings options. The infusion of new 
and advanced technology will dramatically change how finance processes military pay 
documents. 
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B. OBJECTIVES 

The goal of our research is to dramatically improve critical measures of process 
performance which we define as cost, customer service, and document cycle time in both 
the Army and Coast Guard. We do this by redesigning the Military Pay Document 
Process of the Army and Coast Guard. 

The Military Pay Document Process (MPDP) as we define it is the process in 
which the soldier or sailor can make amendments or changes to his or her Master Military 
Pay Account (MMPA). Some examples of affected transactions include the start and stop 
of allotments for U.S. Savings bonds or Life Insurance policies, change to tax exemption 
status, change of financial institution or Direct Deposits, and change to employee 
withholding allowance. The bottom-line is that the customer (soldier/sailor) controls the 
pay items just mentioned. They can only be initiated by the soldier/sailor and have a 
direct impact on the soldiersVsailors' MMPA and take home pay. 

C. RESEARCH QUESTIONS 

This research is focused on answering a primary question "How can the Military 
Pay Document Process be redesigned to improve critical measures of performance?" In 
order to answer this question a set of sub-questions is focused on and answered: 

• What is the current MPDP? 

• What pathologies and problems can be observed in the Army and Coast Guard 
MPDP? 

• How can the MPDP be improved and what are the expected performance 
benefits? 

• What are the MPDP service goals established by the Army and Coast Guard? 

• How can Business Process Redesign (BPR) help the Army and the Coast 
Gu£ird dramatically improve the MPDP? 

• What is the most effective MPDP for the Army and the Coast Guard finance 
communities? 
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D. SCOPE OF THESIS 



The scope of this thesis includes an overview of the current Military Pay 
Document Processing Procedures and technology, as well as the existing goals of the 
Army and the Coast Guard financial communities. Current initiatives to redesign the 
Military Pay Document Processing process are examined along with analyzing existing 
pathologies and problems with current customer service. This information assists in the 
redesign of the MPDP to improve critical performance measures for the Army and the 
Coast Guard. 

E. RESEARCH METHODOLGY 

The research techniques used for this thesis include a thorough literature review 
of the following topics: Business Process Reengineering, Military Pay Document 
Process, Department of Defense Financial Management, and the Department of 
Transportation General Guidelines for customer service. A review of selected Army and 
Coast Guard units’ Standard Operating Procedures is completed, surveys are 
administered, and personal interviews are conducted with soldiers and sailors. The 
authors use Extend + BPR software to model and simulate the MPDP. We first model the 
baseline process of the MPDP, diagnosing process pathologies and faults, and then 
generate redesign alternatives. 



F. CHAPTER OUTLINE 

This thesis is organized as follows. Chapter II provides background information 
on the evolution of the Military Pay System (MPS) processes, and Business Process 
Reengineering. Chapter III discusses the tools used to develop, analyze and redesign the 
current Military Pay Document Process. Using these tools, the authors model the 
baseline process, analyze process pathologies and measure the components and 
performance of the MPDP. Chapter IV generates redesign alternatives, models these 
alternatives, and analyzes the new process based on the critical measures of performance. 
Chapter V concludes with recommendations, and future research topics. 
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II. BACKGROUND 



The mission of the Army and the Coast Guard (CG) finance community is to 
provide military pay support for active duty, reserve, and retired soldiers and sailors who 
assist Commanders in accomplishing their mission. These organizations are also 
responsible for the computation and disbursement of travel allowances, payment of 
commercial vendors, and disbursement of public funds necessary to support the presence 
of the United States Army and the United States Coast Guard in foreign areas. As one 
can see, the responsibilities of these two organizations are diverse and immense. One of 
the most important missions for both financial organizations is military pay support for 
active duty soldiers and sailors in the Department of Defense (DOD) and the Department 
of Transportation (DOT) respectively. To accomplish this mission DOD and DOT have 
increased the level of automation to speed up the processes involved in performing 
military pay transactions. Although automation has improved the Military Pay Document 
Process (MPDP) for the Army and the CG, little has been done to reengineer the 
processes associated with the MPDP. 

The need for reengineering the Military Pay Document Process to reduce cost and 
cycle-time, and increase customer satisfaction, has never been greater. We can't continue 
to embrace the Adam Smith theory that says people are most efficient when they have 
only one easily understood task to perform. Hammer (1993) points out that simple tasks 
demand complex processes to knit them all together, and for many years corporations and 
government agencies have accepted the inconvenience, inefficiencies, and costs 
associated with complex processes in order to reap the benefits of simple tasks. This way 
of thinking is predicated on the Industrial Revolution, when specialization of labor and 
economy of scale promised to overcome inefficiencies of the cottage industries. [Hammer 
and Champy, 1993] 

Most of the processes used by the Army and the CG were developed before 
modem computers and communication systems existed. As the Army and CG financial 
systems aged, processes (both documented and undocumented) evolved to deal with the 
situations encountered. Instead of being designed using a stmctured approach, the 
process mutated to what we define as the baseline Military Pay Document Process. 
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A. MILITARY PAY AND ALLOWANCES 

The process of paying soldiers and sailors has a rich history and interesting 
evolution. By examining the history and the evolution of the Military Pay Document 
Process, we can observe and note the impact technology has on these processes, while 
examining how the processes have changed in light of technological advances. Here we 
show that technology has increased the speed and accuracy, and in some cases the 
flexibility, of making pay changes for soldiers and sailors; however the process 
associated with making pay changes has changed very little, if at all, in the last century. 

The current information age has not had the expected impact on process 
innovations, since applying technology has typically meant merely automating or 
speeding up existing processes. Two fundamental problems exist when this happens. The 
first is while processes might have been improved, they were never engineered to begin 
with. Secondly, continuously improving existing processes simply means that one's often 
doing better what should never have been done at all. [Diamond, 1998] 

1. Evolution of the Military Pay Document Process 

The U.S. Army Finance Corps originated on June 16, 1775, when the Second 
Continental Congress introduced a resolution appointing James Warren as the first 
Paymaster General for the Army. In 1775 a captain received $20, a lieutenant $13, a 
sergeant $8, and a private $6 each month. The process of paying soldiers required the 
Paymaster at Army Headquarters to compute monthly payrolls in his office and then he 
went to the field with his "box" of gold and a military guard to pay the soldiers. 
Obviously payday was not the and 15* day of each month, as we know it today. 

Furthermore, soldiers received no additional entitlements or allowances and had no 
control over how their pay was dispersed or allotted. In a second resolution on 22 June 
1775, congress required General Warren to pay all troops of the army on a monthly basis. 
This ambitious requirement took more than 100 years before it could be performed 
consistently. 

Since then the Army has used more modem methods for paying and making pay 
changes to soldiers' pay accounts. Over the past five decades, the Army has implemented 
four primary pay systems to perform its mission. These four systems include the Finance 
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Document Record Folder (FDRF) System, Joint Uniform Military Pay System (JUMPS), 
Jumps Automated Coding System (JACS), and the Defense Joint Military Pay System 
(DJMS). Each system and the MPDP associated with it are discussed in the following 
paragraphs. 

The Finance Document Record Folder System was implemented in the early 
1900's. This was a manual system that required each finance office to maintain a folder 
for each soldier that was assigned to a particular installation. This folder contained all the 
financial transactions that were processed by the finance office for a soldier. The 
information contained in this folder was used to compute soldiers' pay at the end of each 
month. 

The Military Pay Document Process used the FDRF system; If a soldier wanted to 
make a change to his account he would report to his Military Personnel Office (Milpo) 
and retrieve the necessary documentation. After the soldier completed the 
documentation, he returned it to the Milpo clerk. The Milpo clerk batched several 
documents together (from other soldiers) and forwarded them to finance for processing. 
When the documents arrived at the finance office, a receiving clerk reviewed them for 
correctness. Documents that were not prepared correctly were returned to the unit that 
sent them. If the document was correct, a copy was placed in the soldier's folder. The 
other copies were batched together and mailed to the United States Army Finance and 
Accounting Center (USAFAC) in Indianapolis, IN (USAFAC later became the Defense 
Finance and Accounting Service (DFAS). 

The Joint Uniform Military Pay System was implemented about 1968. This 
system took advantage of the latest keypunch technology to automate the process of 
making pay changes to a soldier's pay record. The FDRF was renamed the Personal 
Finance Record (PFR). Each finance office continued to maintain a PFR for each soldier. 

The Military Pay Document Process used JUMPS: The process didn't change 
much. Soldiers were still required to go to their Milpo and get advice and documents 
from the persormel clerk. The preparation and routing of the docimients using JUMPS 
were virtually the same as with the FDRF system. The difference in the FDRF and 
JUMPS was most evident in the finance office. The real difference is that once 
documents were inside the finance office, they were married with a soldier's PFR. Many 
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PFRs and documents were placed on a block ticket and forwarded to a finance clerk who 
would prepare the keypunch forms by hand for each transaction. The block ticket with 
the keypunch forms were forwarded to the quality edit section where the forms were key 
punched in "80-80" cards. After the keypunch listings were verified for correctness, they 
were transmitted to USAFAC to update a soldier's pay account. Using JUMPS USAFAC 
automated the calculation of soldiers' pay. 

The JUMPS Automated Coding System was implemented about 1983. JACS 
used even more advance technology to accomplish the mission of making changes to 
soldiers' pay accoimts. JACS hardware consisted of an IBM mainframe at USAFAC, 
which centralized all soldiers' pay accounts, and remote terminals in each finance office. 
The PFRs were eliminated and the documents were coded in 80-80-card format using the 
remote terminals. The coded information was stored on a local mini computer at each 
finance office until the end of the day, at which time it was copied to tapes and 
electronically transmitted to USAFAC to change the soldier's pay account. 

The Military Pay Document Process used JACS: This new system represented no 
change in the process. It simply allows the old process imder JUMPS to be done faster. 
However, this process added another layer of controls, by requiring two coders to code 
the exact same document (The coders were commonly known as "coder one" and "coder 
two"). A reviewer verified both coders' transactions for correctness. The transactions that 
were coded correctly were saved for later transmission. This additional layer of controls 
negated any perceived benefit of automating the JUMPS process. While the objectives of 
these controls may be laudable, many organizations fail to recognize the cost associated 
with strict controls. [Hammer and Champy, 1993] This is a classic case of embedding 
outdated processes in silicon and hardware. Hammer (1990) might suggest that the 
process be obliterated and use the new technology to radically improve the process not 
just automate the existing process. 

The Defense Joint Military Pay System was implemented about 1994. This is the 
current system used by DOD. This is a personal computer (PC) based system. There is a 
centralized database stored on an IBM mainframe located at DFAS-Indianapolis, which 
contains the master military pay account (MMPA) for each soldier in the Army. 
Consequently, a finance clerk via PC and a direct connection from the military 
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installation to DFAS can access any soldier's MMPA. Under DIMS coder two was 
eliminated. However there is still a reviewer. 

The Military Pay Document Process used DIMS; The soldier is required to go to 
his Personnel and Administration Clerk (PAC) to receive the necessary forms and some 
limited advice. The PAC is the same organization as Milpo with the same basic function 
— the name just changed. PAC clerks are personnel specialists, not finance specialists; 
therefore they are not always able to give the best advice concerning finance pay change 
issues. The major change is that the documents are coded on a PC downloaded to a 
floppy disk and uploaded directly to the database at DFAS-Indianapolis. The changes to 
the soldiers' MMPA are made much faster once the information is uploaded to DFAS- 
Indianapolis. 

The Coast Guard (CG) has experienced a similar evolution in its Military Pay 
Document Process (MPDP) from a manual system, called the "Yellow Card", to an 
automated pay system called "Standard Workstation" (SWS). The CG has implemented 
two different pay systems to help improve the performance of the pay mission. These 
systems are the Yellow Card and JUMPS. Under JUMPS the CG has used mainframe and 
dummy terminal technology as well as PC based technology. 

The Yellow Card System was implemented in 1915. This "card" looked 
something like an accounting ledger and all the transactions for a sailor's account was 
recorded on it. The card reflected the sailors' base salary as a credit and on the 1 5'*’ and 
30^ of the month when the sailor was paid his card would be manually annotated with a 
debit for the amount of the sailor's pay. 

The Military Pay Document Process used the Yellow Card: In the pre-automated 
days, the member would go to his unit Yeoman and request the necessary forms to make 
a pay change. The sailor's unit Yeoman forwarded the documents to the local Personnel 
and Service Unit (PERSU). The PERSU Yeoman manually posted the pay changes to 
the sailor's yellow card. In the case of an allotment, the form would go to the pay office 
for posting to the member's yellow pay card. In the case of a marriage, a copy of the 
marriage certificate would have gone to the personnel office for an update to the 
member's service record. Then the personnel office would have sent notice to the 



9 



PERSRU to record the basic allowance for quarters (BAQ) entitlement on the yellow pay 
card. 

This process of making changes to a sailor's card is similar to the process used 
today to make changes to a sailor's master military pay account located in a centralized 
database. With the early yellow card system, there were about 500 Yeomen throughout 
the CG that performed the necessary transactions for sailors each month. 

Joint Uniform Military Pay System (JUMPS) was implemented in 1983. The 
manual process of recording sailors' transactions was automated using JUMPS. JUMPS 
allowed the CG to establish a centralized finance center with 200 people designated to 
handle pay and personnel transactions for sailors. This system eliminated many of the 
500 Yeomen used when the process was manual. JUMPS ran on a Wang mainframe and 
used remote terminals at the local PERSUs. This system was known as SWS I. 

The Military Pay Document Process used JUMPS: As noted by the Chief of 
Military Pay Support, Human Resource Service and Information Center (HRSIC), 
Topeka, KS, "The current automated process is not much different than when we used 
the yellow cardboard pay cards." Under JUMPS a sailor making changes to his pay 
account consulted with his unit Yeoman who advised him on financial matters. The 
service member prepared the necessary documents and returned them to the unit Yeoman 
who verified them for correctness. The unit Yeoman batched documents together and 
forwarded them, via mail, to the servicing PERSRU where a PERSRU Yeoman retrieved 
the documents. The PERSU Yeoman verified the documents for correctness and coded 
the transactions on SWS I. The PERSU Yeoman then handed the documents to a 
transmittal Yeoman inside the PERSRU. The transmittal Yeoman electronically 
transmitted the coded information to HRSIC daily. HRSIC downloaded the information 
file and batched the transactions with transactions from other PERSRUs. Once a week, 
HRSIC ran a batch job against the master military pay database to update sailors' master 
military pay record. 

Currently JUMPS is being updated and is now PC based with better 
communication access to HRSIC from the local PERSUs. Although the automated 
process is a big improvement over the manual process, the fundamental process has not 
changed. 
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2. The Service Goals for the Military Pay Document Processing System 

The Coast Guard and the Army have established service goals for the MPDP. As 
a part of the reengineering process we will consider the goals of each service. The MPDP 
goals for the Army are to provide quality financial services to customers, reduce finance 
and accounting cost, provide the objective information infrastructure, and increase the 
competence of financial management workforce. [DFAS, 1998] The MPDP goals for the 
CG are to move personnel support closer to the units serviced, integrate procedures and 
system configuration, reduce process complexity, improve current personnel/pay 
processes, provide flexible access to personnel and pay data, reduce annual operating 
costs. [Coast Guard Goal] 

B. BUSINESS PROCESS REENGINEERING 

Reengineering originated in the private sector as a method for helping companies 
sustain and preferably increase market shares in a competitive and dynamic marketplace. 
Although the reasons for change may be different for government -- such as increasing 
workload, shrinking budgets, and personnel reductions -- the need for significant 
performance improvement is no less imperative. 

1. Reengineering Overview 

Business Process Reengineering (BPR) is an approach to dramatically improve 
operating effectiveness through redesigning critical business processes and supporting 
business systems, as opposed to incremental improvements. Hammer and Champy 
(1993), well known reengineering experts and creators of a best selling book, define 
reengineering as "the fundamental rethinking and radical redesign of business processes 
to achieve dramatic improvements in critical, contemporary measures of performance, 
such as cost, quality, service, and speed". Hammer and Champy provide further insight 
into their definition by identifying four key words: fundamental, radical, dramatic, and 
processes. These key words are discussed in detail in the succeeding paragraphs. 

The first word fundamental implies that organizations must clearly understand 
why they exist. Once that's clear, they must intimately understand why they do what they 
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do. Hammer and Champy suggest that organizations should answer two questions: Why 
do we do what we do? And why do we do it the way we do? Government organizations 
are especially guilty of operating according to ad hoc rules, which have evolved over 
time but are no longer are appropriate. Military organizations are notorious for writing 
pages of standard operating procedures, which are rules governing the way an 
organization operates. However, most of these SOPs are out dated and have little 
congruency with the current organizational environment or customer needs. By 
redesigning processes new SOPs will emerge focused on customers and their needs, 
ignoring what is and concentrating on what should be. [Hammer and Champy, 1993] 

The second key word is radical. This word is derived from the Latin word 
"radix" meaning root. Getting at the root of the problem, finding out what makes the 
process work the way it does and why it has to be done that way. Hammer suggests that 
outdated processes should be obliterated and redesigned properly from scratch. [Hammer, 
1990] Hammer and Champy (1993) characterize reengineering as a "clean sheet" 
approach to radical change. The clean sheet approach draws direct contrast to the 
incremental approach of process improvement. 

Process improvement is about enhancing or improving existing processes. 
Consequently one may improve or speed up a process, with automation, that should never 
have been done in the first place. Hammer suggests that "it's time to stop paving the cow 
path and use computers to redesign - not just automate existing processes." [Hammer, 
1990] Reading the evolution of the MPDP for the Army and the CG, one can see that the 
current MPDPs in both services are simply old processes, which have been speeded up 
using automation. Although some improvements have been made in the process speed, 
dramatic improvements will require radical changes in the process. 

The key word dramatic enforces the notion that BPR is not about making 
marginal or incremental improvements, but about achieving quantum leaps in 
performance. Organizations expect an order of magnitude in performance gains from a 
reengineering approach. While some may debate it, most experts would agree that 
reengineering is an all or nothing proposition that delivers major gains in performance. 
In order to achieve this sort of performance improvement, the Army and the CG finance 
community must "break away from conventional wisdom and constraints of 
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organizational boundaries". [Hammer and Champy, 1993] Dr. Sharon L. Caudle (1995), 
who wrote her dissertation on her experiences with reengineering government agencies, 
suggests that processes cross functional units and/or organizational boundaries to involve 
other organizations or individuals. In fact, a business process is basically independent of 
formal organizational structural arrangements and reporting relationships. A process is 
how the organization delivers value to the customers, regardless of the hierarchy and 
vertical structural designs. For most military managers who are anchored to their 
functional area, this is a very different view. Caudle says the "functional foxholes" of 
areas such as personnel, finance, budgeting, operations, and evaluation must be 
transformed into "process streams". Organizations as traditional as the military must 
replace their vertical view of independent functions with a horizontal view of many 
interlocking processes. [Caudle, 1995] 

Based on Caudle's studies of government organizations and their composite 
experiences, she has developed a definition for government reengineering. 

Government business process reengineering is a radical 
improvement approach that critically examines, rethinks, and designs 
mission-delivery processes and sub-processes. In a political environment, 
it achieves dramatic mission performance gains from multiple customers 
and stakeholder perspectives. It is a key part of a process management 
approach that continually evaluates, adjusts, or removes processes or sub- 
processes for optimal performance." [Caudle, 1995] 

There are other reengineering practitioners who have come up with their own 
definitions for reengineering. In essence, they boil down to a systematic approach, not 
necessarily done the same way by everyone, that allows managers, subordinate managers, 
and line workers to fundamentally reexamine, rethink, and redesign old ways of doing 
business — achieving dramatic, measurable improvements in critical measures of 
performance. Reengineering is about fundamental change. 

While scholars and non-scholars may define reengineering slightly different, most 
will agree that customers ultimately define value, and without a customer focus, an 
organization risks missing what matters most in achieving its mission. They will also 
agree that reengineering critically examines the underlying assumptions about how an 
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organization conducts its work, examining not only the work processes, but the 
underlying business rules that dictate how work is performed. Although reengineering 
can be a highly complex and high-risk endeavor, organizations that have reengineered 
successfully generally followed a set of identifiable practices and a soimd methodological 
approach. While reengineering reaches far beyond business process to achieve the 
dramatic performance gains, it is not a panacea; it is one element of a comprehensive 
process management program. [GAO, 1995] 

The desired outcome of reengineering is a customer-focused organization that 
experiences extraordinary gains in productivity. "Reengineering ~ with its radical 
changes in areas such as work flow, rules and regulations, job content, job skills, 
decision-making, and information systems — is the only thing that can bring about 
[dramatic] improvement in either the total process or a process' major sub-processes." 
[Caudle, 1995] 

2. What Will Be Measured? 

Business process reengineering is a structured approach that relies on, 
performance measurement to determine which process to reengineer and to determine if 
proposed changes will have a productive impact. Performance measurements are defined 
in this thesis as an indicator that can be used to evaluate quality, cost, or cycle time 
characteristics of an activity or process usually against a target or standard value. It is an 
established, consistent way to measure the rate of change within an organization. 
However, performance measurements alone do not provide enough insight to redesign the 
process to improve performance. Consequently, a means for measuring the components 
of the process, identifying process pathologies, and identifying possible redesign 
alternatives is needed. The tool used to accomplish this is called KOPeR. This tool is 
discussed in detail in Chapter III. The authors will measure the MPDP performance 
using the performance measurements in Table 1 and the process components using the 
measures in Table 2. 
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Table 1 Performance Measures 



Measurements 


Deflnition 


Cycle Time 


The measurement of the time an item remains in the process, 
either in the entire process or in a specific part of it. Cycle time 
measures how long it takes to get from point A to point B (e.g., 
beginning to end). 


Cost 


The price or imputed value of each resource assigned to an activity 
that is consumed in the process of producing the products and 
services of that activity. 


Quality of Service 


The traditional definition states that quality is the degree of 
excellence possessed by a product, service, or other output of a 
business activity or business process. We define quality as, how 
well the process conforms to the customers' requirements. 



Table 2 Process Measures [Nissen, 1994] 



Measure 


Definition 


Process Length 


Number of nodes in longest path 


Process Breadth 


Number of distinct paths 


Process Depth 


Number of process levels 


Process Size 


Number of nodes in process model 


Process Feedback 


Number of cycles in process graph 


Parallelism 


Process Size divided by Length 


IT Support 


Number of IT-support attributes 


IT Communication 


Number of IT-communication attributes 


IT Automation 


Number of IT-automation attributes 


Process Handoffs 


Number of inter-role edges 


Value Chains 


Number of unique activity Value Chain attributes 



3. How Will The MPDP Be Changed? 

To achieve the dramatic improvements that BPR can bring, the authors consider 
making changes to the MPDP by eliminating non-essential, non-value-adding steps. 
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implementing and inserting technology where appropriate, improving workflow to 
emphasize value-adding functions, providing metrics for meaningful analysis and 
strategic planning, moving pay support closer to the customer, reducing current system 
complexity that drive cost, combining several jobs into one, reducing unnecessary checks 
and controls, and allowing work to be performed where it makes the most sense. 
[Hammer and Champy, 1993] 

Service organizations, such as the financial communities of the Army and the CG, 
must put their professed commitment to customer satisfaction at the center of the 
redesign effort. In government organizations, the authors note from their own 
experiences that service workers or finance clerks are unable to satisfy the customer 
because they must follow strictly defined rules, and lack the authority to make exceptions 
or the resources to complete a transaction. Therefore, the authors seek to redesign the 
MPDP making the customer the starting point for change. 

4. Overview of Business Process Redesign Methodologies 

Our research efforts to find a structured approach to BPR left us somewhat empty 
handed. Although there are many opinions and keen insight to BPR, there is little detail 
about what specific steps to take to reengineer the identified processes. However, Sharon 
Bitzer's (1995) thesis, Worl0ow Reengineering: Business Process Reengineering with 
Workflow Management Technology, does an excellent job evaluating four different 
methodologies from four different BPR practitioners. The four published methodologies 
evaluated by Bitzer are from Mark Klein, Thomas Davenport, H. J. Harrington, and the 
Department of Defense. The authors encourage the reader to examine each methodology 
in more detail prior to beginning a reengineering project. The intent of the authors is to 
review the evaluation made by Bitzer and determine an appropriate methodology to use 
in redesigning the MPDP. 

Bitzer compares each methodology against the characteristics outlined in the 
Department of Defense (DOD) manual on business process reengineering. According to 
Bitzer, DOD states that an effective methodology for change must conform to the items 
in Table 4 (DODINST 8020.1 -M, 1993). 



16 



Table 3 DOD Characteristics of an effective methodology 



Item 


Definition 


Complete: 


It must provide steps that direct a business process improvement 
procedure from establishment to implementation. 


Applicable: 


The methodology must be able to be used on any process of the 
business. 


Friendly: 


The procedure must be easy for all personnel, including non- 
technical workers and managers, to learn and imderstand. 


Consistent: 


It must be the only method used to conduct reengineering within 
the organization. This will allow in-house reengineering 
expertise to be developed. 


Supported: 


The engineering procedure must include detailed 
documentation, training courses and project management tools. 


Successful: 


The methodology should have a record of success and these 
cases should be available to guide the actions of the 
reengineering team. 


Documenting: 


The procedures must produce process documentation as it is 
used. 


Enabling by Tools: 


The method must be supported by automated tools that help ease 
the reengineering workload and enable process documentation 
and measurement 



Bitzer (1995) concluded in her evaluation of the four methodologies that Klein's, 
Davenport's, and Harrington's methodologies do not exhibit all the characteristics of an 
effective methodology. Bitzer rejects Klein's methodology because it does not specify 
any tools, automated or not, and it gives no examples of the methodology's success. 
Davenport's methodology is rejected because "it is not comprehensive". Bitzer notes that 
Davenport fails to specify steps for gaining management support. He focuses most of his 
attention on gaining a greater understanding about what the process should do, while his 
methodology, in Bitzer's opinion, lacks direction on how to identify changes to a process. 
Bitzer suggests that Harrington's methodology is the most complete. While furnishing 
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detailed steps, Harrington provides guidance on how to organize for improvement, what 
data should be collected prior to analyzing a process, and he provides guidance on how to 
improve the process. However, Bitzer also rejects Harrington's methodology because it 
does not specify computerized software tools to be used during the redesign process, nor 
does it mention any simulation tools used prior to implementation. Of all the 
methodologies evaluated, Bitzer noted DOD's methodology as being the most 
comprehensive and the one that most closely exhibits the characteristics of an effective 
methodology. Bitzer evaluated DOD's methodology as the best. However she noted that 
the modeling tool specified for use by the methodology is complicated and lacks the 
integration of process modeling, cost analysis, and simulation. 

A methodology not included in Bitzer's thesis is one developed by Nissen. This 
methodology is a unique blend of several of the methodologies discussed above. As 
noted, all above methodologies contain some faults. Most importantly, Nissen's synthesis 
of several expert methodologies creates a methodology, which supports process 
measurements with "rigor and precision". [Nissen, 1997] 

5. Methodology Used To Redesign MPDP 

Following these steps, the authors use Nissen's methodology (see Figure 1) to 
redesign the MPDP. The steps associated with this methodology are as follows: 

1 . Identify the process 

2. Model the process 

3. Measure the configuration 

4. Diagnosis the pathologies 

5. Match the transformations 

6. Generate redesign alternatives 

7. Test redesign alternatives 

8. Select preferred choice 

The authors identified a sub-process of the Military Pay System for the United 
States Army and the United States Coast Guard. The MPDP, defined in Chapter I, was 
chosen because it presents an excellent opportunity for dramatic improvement. Experts 
suggest the reengineering should consider processes with the most possibility for 
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dramatic improvement. Based on one author's first hand knowledge and nine years of 
experience as a finance officer, he concludes that reengineering the MPDP has potential 
for dramatic improvement. Using Extend + BPR modeling and simulation software the 
authors model the baseline (i.e., "as-is") process and measure the process cost, cycle time, 
and quality (see Table 2). Using KOPeR (pronounce "cope-er") the baseline process 
configuration is measured (see Table 3 Process Pathologies). These measurements "drive 
the diagnosis of process pathologies" (see Table 5). [Nissen, 1997] After measuring the 
process and diagnosing the pathologies we "treat" the pathologies by matching the 
redesign transformations (see Table 4 Redesign Transformations) available. During this 
step the authors look at technology, workflow, and information available to improve the 
process. Based on the diagnosis and treatment recommendations, redesign alternatives are 
developed. Using Extend + BPR, the critical performance measures of the redesigned 
alternatives are compared with those of the baseline model to determine if treatment was 
effective. By testing the redesign alternatives, using modeling and simulation, 
performance is compared to the baseline benchmark to determine the performance 
improvement. KOPeR and Extend + BPR tools are discussed in Chapter III. [Nissen 
1997] 




Figure 1 - Redesign Process Methodology (KOPeR approach) 
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III. MODEL DEVELOPMENT TOOLS AND "AS-IS" PROCESS 



A. MODEL DEVELOPMENT TOOLS 
1. EXTEND 

EXTEND + BPR modeling and simulation software is used to model the MPDP 
and assesses the performance of the baseline process as well as the relative performance 
improvements of the process' redesign alternatives discussed in Chapter IV. 

a. EXTEND Overview 

EXTEND + BPR is an object-oriented environment for modeling, 
analyzing, reengineering, and documenting processes. It uses an iconic building-block 
paradigm to facilitate communication and allows the authors to concentrate more on 
process design than on any particular methodology. The MPDP is composed of real- 
world elements and processes that interact when specific events occur. Using EXTEND 
+ BPR, the authors are able to simulate the MPDP system using blocks which mimic the 
real-life processes and timing that represent the actual occurrence of events. The blocks 
used in EXTEND + BPR directly correspond to the activities (coding documents), queues 
(in/out boxes), delays (cycle time), and transformations that comprise the process to be 
redesigned. 

Using EXTEND + BPR the authors can easily incorporate high-level 
reengineering concepts such as batching, cycle timing, activity-based costing, and 
conditional routing. This software is excellent for the redesign of the MPDP, for it de- 
mystifies modeling and simulation and allows non-technical personnel, such as managers 
and the people who do the work, to utilize simulation for analysis and redesign of 
business processes. The authors use this software to assist in answering the primary 
question proposed by this research; How can the Military Pay Document Process be 
redesigned to improve critical measures of performance such as cost, cycle time, and 
customer service. Measurements and predictions about cycle time, cost, quality, and the 
cost of implementing alternatives serve as a basis for developing high-performance 
alternatives that can get the Army and the CG financial communities from the "as-is" to 
the "to-be". However, developing a specific strategy to go from the "as-is" to the "to-be" 
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design is beyond the scope of this thesis and is recommended for future research. 
Following the redesign methodology discussed above the authors use the information 
obtained from KOPeR and EXTEND + BPR simulation to generate and test promising 
redesign alternatives. 

b. Input Variables for EXTEND 

EXTEND requires input data and variables to drive the model. Time 
dependent data such as document arrival time and document review time is one type of 
data that is necessary. The other type of data is probabilistic data - data such as the 
probability of a document being rejected by the finance-receiving clerk. These variables 
allow the authors to measure cycle time. Cost data is also important to compare relative 
cost of process alternatives. To obtain the input variables the authors consulted with an 
Army finance unit (Table 4 Input Variables - US Army) and a Coast Guard PERSRU 
(Table 5 Input Variables - US Coast Guard). The input variables are a result of 
interviews with senior finance personal who are intimately familiar with the details of the 



MPDP. 

Table 4 Input Variables - U.S. Army 



Variables 


Distribution alue (avg.) 


Source (averages) 


PAC Process 






Document arrival rate - 
PAC 


5 min (per document) 


Expert estimate 


Document review rate - 
PAC 


6 min (per document) 


Expert estimate 


Prepare Transmittal Letter 


1 min (per document) 


Expert estimate 


Number of Documents 
remaining in the PAC's 
inbox from the prior day 


4 per day 


Expert estimate 


Delay time for unit PAC to 
courier documents to 
finance 


30 min 


Expert estimate 
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Finance Process 






PAC arrival rate - Finance 
Office 


15.45 min 


Expert estimate 


Document review rate - 
Finance Office 


5.25 min 


Expert estimate 


Document processing rate - 
Finance Office (per 
coder/per batch) 


17.14 min 


Expert estimate 


Hourly regular military 
compensation. 


$9.03/per hour 


1999 Pay Tables (E-4 
with 3 years of service) 



Table 5 Input Variables - U.S. Coast Guard 



Variable 


DistributionA^alue (avg.) 


Source 


Unit Yeoman Process 






Document arrival rate - unit 
Yeoman 


30 min (per document) 


Calculated from data 


Document review rate - unit 
Yeoman 


5 min (per document) 


Expert estimate 


Number of Documents 
remaining in the Yeoman's 
inbox from the prior day 


3 per day 


Expert estimate 


Delay time for unit Yeoman 
to courier documents to 
finance 


3.5 hours 


Expert estimate 


PERSRU Process 






TL arrival rate - PERSRU 


1 8 min (per TL) 


Expert estimate 


Document review rate - 
PERSRU 


10 min (per TL) 


Expert estimate 


Document processing rate - 
PERSRU (per coder/per 
batch) 


20 min (per TL) 


Expert estimate 


Hourly regular military 
compensation 


$10.3 8/per hour 


1999 Military Pay Tables 
(E-5 with 5 years of 
service) 



23 




The exponential function is widely used to analyze times between 
independent events such as arrival times. Many phenomena are exponentially 
distributed, such as the times between arrivals of aircraft to an airport and the time 
between documents arriving at the finance office. [Pegden, Shannon and Sadowski, 1995] 
Pegden, Shannon and Sadowski (1995) note that when determining input variables, 
reliance on the following sources may prove to be the best option: 1) operators, 2) vendor 
claims, and 3) theoretical considerations. Therefore it is assumed that the document for 
the MPDP arrival time is exponentially distributed. The document arrival time for the 
Army PAC is 5 minutes per document. PAC clerks arrive at the finance office with a 
batch of documents every 15.45 minutes. The document arrival time is also exponentially 
distributed for the CG with one document arriving at the unit yeoman's office every 30 
minutes and a unit yeoman arriving at the PERSRU with a batch of documents every 1 8 
minutes. 

2. KOPeR 

a. Overview 

Knowledge-based systems (KBSs) are used to support process redesign. 
KOPeR (knowledge-based organizational process redesign - pronounced "cope-er") is a 
proof of concept system KBS, which provides an automated reengineering method to 
evaluate redesigned alternatives. "The KOPeR design draws from the artificial 
intelligence (AI) methods and technologies, which allow it to capture process redesign 
knowledge from the reengineering literature and practice through twin taxonomies and 
production rules." [Nissen, 1997] 

Nissen defines KOPeR as a graphed based tool (i.e., comprised of nodes, 
edges, and attributes), which produces a battery of graph-based diagnostic process 
measures automatically. As diagnostics these measurements are used to detect severe 
pathologies and faults associated with a process. KOPeR employs a base of formalized 
reengineering knowledge (i.e., knowledge base) to predict which design transformations 
are most likely to effect dramatic improvement in process performance. These 
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transformations are then applied to the baseline (i.e., "as-is") process model to generate 
one or more re-design alternatives. [Nissen, 1997] 

Once the process model has been validated and calibrated against the 
process baseline, EXTEND + BPR simulation software is used to test the performance of 
each redesign alternative. Combining the KOPeR model with EXTEND + BPR 
represents an efficient technique when evaluating alternate process redesigns, and it helps 
reduce the inherent risks of reengineering by providing a method to evaluate redesign 
alternatives before committing time and money. 



b. Input Variables 

Simulating the baseline process using EXTEND + BPR provides a 
graphical depiction of the process for applying KOPeR. The graphical depiction of the 
process is used to calculate the measures for the MPDP "as-is" and "to-be" process (i.e., 
steps, length, breadth, depths, size, feedback, parallelism, handoffs, information 
technology support (IT-S), information technology communication (IT-C), and 
information technology automation (IT-A)). Figure 2 shows an example of how graph 
based measurements can be used to represent the inputs to KOPeR for redesign. [Nissen, 
1994] 
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Figure 2 - Process Model 



In order to evaluate these measures, a Level 1 and Level 2 baseline 
representation is developed for each organization. Then the input variables needed for 
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KOPeR are calculated as described in Chapter II, Table 2. In the following two sections 
we begin the first step of Nissen's methodology by describing the "as-is" MPDP for the 
Army and the CG. 

B. UNITED STATES ARMY MILITARY DOCUMENT PROCESS 

This section describes the "as-is" MPDP for a United States Army finance tinit 
providing pay support to soldiers co-located on the same installation. Although the 
process description is that of a particular finance unit, it reflects the process flow of most 
finance units. 

1. "AS-IS*' Process Description 

The U.S. Army MPDP is a linear batch process. Soldiers create documents by 
requesting pay changes. The documents are given to the soldier's unit personnel and 
administration clerk (PAC), who couriers the documents to the finance office for 
processing. At the finance office the documents are reviewed, coded, and transmitted to 
DFAS. At DFAS the documents are processed against the soldier's master military pay 
account (MMPA). A level 1 schema of this is represented in Figure 3. Figures 4 and 5 
show the decomposition of the PAC processes and the finance office process 
respectively. 




Figure 3: US Army level 1 schema ("AS-IS") 



The detailed process is as follows: A soldier decides he wants to initiate a pay 
change (Typical pay transactions are listed in Table 6). The soldier reports to his 
personnel and administration clerk (PAC) to retrieve the necessary forms. In some cases 
the form(s) can be downloaded from the World Wide Web (WWW). The soldier 
prepares the document(s) and returns it to the PAC. The PAC reviews the document(s) 
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for completeness and correctness and batches it with other documents received from 
other soldiers. The PAC covers the batched documents with a transmittal letter (TL) 
which lists all the documents in the batch and couriers the documents to the finance 
office. 




A receiving clerk at finance reviews the documents again for completeness and 



correctness. Documents that are not prepared correctly are given back to the PAC clerk. 
The receiving clerk takes the documents to the coding section where they are sorted by 
type and placed in a document bin. Coders retrieve documents from the document bin 
and process them. At the end of the day the coder saves the coded transactions onto a 
floppy diskette, makes a hardcopy printout of the coded transactions and gives the 
hardcopy and the documents to the auditor. 
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Figure 5 Finance Office Process (decomposition) 



The auditor reviews the coded transaction given to him by the coder and transmits them 
to DFAS-IN to process against the soldier's MMPA. If the transactions are without error 
the changes are reflected on the soldiers MMPA. If any uploaded transaction is in error, 
the transaction is rejected and is re-worked by the coder. These errors are generally 
corrected immediately with minimal addition to the processing time. 



Table 6 Typical Pay Transactions 



Transaction Form 


Transaction Name 


Transaction Effect 


US Armv 


US Coast 
Guard 






DA Form 3685 


N/A 


Direct Deposit 


Deposits Money To 
specified Financial 
Institution or Bank 
Accounts 
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DD Form 2558 


N/A 


Allotment 
(stop/start/ change) 


Deducts money out of 
sailors pay and sends it 
where directed 
(Insurance Company, U. 
S. Savings Bond 
purchase. Mortgage 
Payment, or Individual) 


DD Form 2058-1 


DD Form 2058-1 


Tax exemption 
status. 


Allows sailor to change 
his tax exemption status. 


DD Form 2559 


DD Form 2559 


Savings Bond 
Allotment 


Deducts Money from 
soldiers pay to purchase 
savings bonds for 
soldier. 



2. Simulation Results of the " AS-IS " Process - U.S. Army 

Table 7 presents a summary of the data obtained from the simulation model. 
Using the level 1 diagram as the starting point, a separate model was created for the tasks 
performed by the unit PAC and the finance office. The tasks performed at DFAS-IN are 
not modeled because they represent the exit point of the MPDP. 



Table 7 Simulation Output Results - U.S. Army 



Measurement 


“As-Is” Model Average Values 


PAC Transaction Processing 




Average Cycle Time per document 


1.36 hours 


Cost of PAC labor 


$ 1 1 5 per day / $3450 per month 


Productivity per PAC clerk per day 


79 per day 


Utilization per PAC clerk per day 


53% average 


Finance Transaction Processing 




Average Cycle Time per document 


16.36 minutes 


Cost of finance labor 


$281 per day / $8430 per month 


Productivity of the finance process 


308 documents per coder 


Utilization 


97% 



The PAC's tasks represent the first process of the MPDP as shown in Figure 4 
above. By setting EXTEND’s modeling parameters based on the data in Table 4, we 
determine the cycle time, productivity, utilization measurements, and cost. As shown by 
the graph in Figure 6, cycle time and average cycle time is plotted on the left axis, while 
productivity and utilization is plotted on the right axis. 
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Figure 6 Army PAC "AS-IS" Results 



Cycle time is the measurement of the time an item remains in a process, either in 
the entire process or in a specific part of it. In this process cycle time represents the actual 
time it takes for the PAC clerk to review documents received from customers and prepare 
a TL. As shown in the graph above cycle time continually increases. While the average 
cycle time is 1.36 hours, documents arriving at the end of the day have a cumulative 
cycle time of approximately 2.5 hours. The increase in cycle time for documents arriving 
at the end of the day is attributed to the standard operating procedures enforced by the 
finance office. PAC clerks have approximately a three hour window of time in the 
morning (0800 until 1100) to bring documents to finance for processing that day. 
Therefore documents received during the first few hours of the day are processed 
immediately. Documents received after 1100 remain in the PAC's inbox until the next 
morning. However it is important to note that PAC clerks do more than process finance 
documents. Processing finance documents is only one aspect of their job. 

Productivity is a ratio of the outputs to the inputs that produce them. Productivity 
is often based on how many items can be output in a particular segment of time. For 
example if a PAC clerk processes 1 1 documents in one day of labor (8 hours), then 
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productivity is 1 1 per day. The simulation results indicate that a PAC clerk can process 
approximately 79 documents per day. However, documents dropped off at the end of a 
day are not reviewed nor added to a TL until the next day. This standard operating 
procedure increases cycle time and reduces productivity. 

Utilization is the ratio of the time busy processing compared to the entire amount 
of time available for processing. Utilization is calculated by multiplying the total time to 
process a document by the number of documents then dividing that number by the time it 
takes to complete the entire process. For example, if it takes 44 minutes to process 1 1 
documents the PACs utilization ratio is 100% based on an eight hour day ((44*1 1)/480). 
The simulation suggests that the PAC process is completely busy, during the first 3 hours 
of the day, when performing the task of reviewing documents, preparing TLs, and 
carrying them to finance. [Diamond, 1998] 

The cost for a PAC clerk to process documents received by a customer, courier 
documents, and wait while the finance receiving clerk reviews the documents is 
calculated using the activity base costing (ABC) functions in EXTEND + BPR software. 
ABC assigns a cost to the service provided based on its use by the process. The analysis 
of cost is used to evaluate the labor cost drivers and helps identify possible savings in the 
redesigned alternatives. Only the direct cost of a clerk's salary is used to determine the 
cost measurement. The cost per clerk is based on the 1999 regular military pay 
compensation for an E-4 (pay rate) with three years of service. The regular military pay 
compensation includes basic pay, basic allowance for subsistence, basic allowance for 
housing, as well as the tax advantage from untaxed allowances. The hourly rate in Table 
4 is used as an input parameter to calculate the cost. PAC tasks are typically, but not in 
all cases, performed by a soldier of this pay rate. The model suggests the cost for the 
PAC process is $115 per day or $3446 per month (based on a 30-day month). This 
amount can be multiplied by the total number of PAC clerks (33 x $3446 = $1 13,718 per 
month) who perform a similar process. One can see that this cost alone can be quite 
substantial over the long term. 

Next we examine the "as-is" measurements for the task performed in the finance 
office. A PAC clerk arrives on an average of every 15.45 minutes with a batch of 
documents. It takes the finance receiving clerk about 5.25 minutes to review a batch of 
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documents and it takes a coder an average of 17.14 minutes to process a batch of 11 
documents. Cycle time, cost, productivity, and utility are determined in the same manner 
described above for the PAC process. The cycle time in the finance process measures the 
time it takes for the finance receiving clerk to review the documents plus the time it takes 
for the coders to code the documents during an eight hour day. Although reworks effect 
cycle time we didn't find it significant enough to merit further consideration. The 
simulation results indicate that the average cycle time is approximately three hours per 
batch (or seven minutes per document). This means a single document takes seven 
minutes to be reviewed by the receiving clerk, processed by a coder, and uploaded to 
DFAS. However, because the processing time is slightly longer than the arrival interval, 
the cycle time increases for documents that arrive at the end of the day. Therefore, the 
cumulative cycle time for a batch in the finance process is approximately five hours (or 
11.5 minutes per document). The utility measurement shows that each coder is busy, 
processing documents approximately 97% of the time during the workday. The cost 
associated with performing this task is $281 per day or $8430 per month. 

3. KOPeR Diagnosis of the "AS-IS" Process - U.S. Army 

Simulating the baseline process using EXTEND + BPR provides a graphical 
depiction of the process for applying KOPeR. The graphical depiction of the process is 
used to determine the process measures shown in Table 8. KOPeR provides intangible 
measurements, which are often ignored when using simulation models alone. The 
measures obtained from KOPeR provide baseline values essential for comparing and 
evaluating redesign alternatives. The comparison allows one to objectively analyze real 
improvements of the redesign alternative vice redesign alternatives that merely represent 
minor changes of the baseline process, with no significant improvement of the process. 
Davenport concludes that there are two primary reasons to measure the process before 
redesigning it: 1) problems must be understood so that they are not repeated and 2) 
accurate measurement can serve as a baseline for future improvements. [Davenport and 
Short, 1990] 
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Table 8 Process Measures U.S. Army 



Measures 


Definition 


Calculated 

Measures 


Process Length 


Number of nodes in longest path 


12 


Process Breadth 


Number of distinct paths 


1 


Process Depth 


Number of process levels 


1 


Process Size 


Number of nodes in process model 


14 


Process Feedback 


Number of cycles in graph 


5 


Parallelism 


Process Size divided by Length 


1.167 


IT Support 


Number of IT-support attributes 


7 


IT Communication 


Number of IT-communication 
attributes 


1 


IT Automation 


Number of IT-automation attributes 


2 


Process Handoffs 


Process Handoffs 


5 



Table 9 highlights the process measures and pathologies identified by KOPeR. KOPeR 
measures suggest that the MPDP baseline process exhibits five pathologies that can have 
an effect on the process cycle time and cost. In this section we examine the pathologies 
and their consequence on process performance. 



Table 9 KOPeR Analysis for U.S. Army ("AS-IS") 



Measures 


Value 


Pathology 


Parallelism 


1.167 


Sequential Process 


Handoffs Fraction 


0.357 


Process Friction 


Feedback Fraction 


0.357 


Checking & Complexity 


IT Support (IT-S) Fraction 


0.5 


Satisfactory 


IT Communication 
Fraction (IT-C) 


0.071 


Inadequate IT communications 


IT Automation (IT- A) 
Fraction 


0.143 


IT requires substantial investment in 
terms of support, training, and 
communication 
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KOPeR’s first measurement is parallelism. The value of 1.167 indicates the 
MPDP is nearly a completely sequential process (1.00 represents a theoretical minimum 
associated with a perfectly linear process). Sequential processes are widely noted by 
reengineering practitioners as problematic in terms of cycle time. This sequential process 
is based on the century-old notion of specialized personnel clerks who perform the 
administrative function (preparing the paper work) and finance clerks who process the 
pay transactions (to effect pay). Sequential processes cause problems, because all the 
data must be available at each step even if it's not needed until a later step. In addition, 
Hammer and Champy (1993) suggest that sequential processes increase confusion - if a 
problem with a customer's requirements arise late in the process, the customer (or his 
documentation) must be referred back to step one, requiring needless delay and rework. 

Next the handoff fraction measure of 0.357 indicates that the process is highly 
departmentalized, resulting in a high level of process friction. Hammer and Champy 
(1993) suggest that handoffs are responsible for numerous errors and misunderstandings. 
Moreover the feedback fraction measurement of 0.357 suggest excessive recheck and 
validation steps. Government bureaucratic organizations are notorious for 
departmentalizing work into "specialized foxholes". Nissen (1998) notes that 
fragmented, specialized organizational approaches can lead to increased cycle time and 
increased cost associated with validation and rechecks. Reducing the handoff fraction can 
positively impact cycle time and cost. 

Finally KOPeR's measurement values for IT-S, IT-C, and IT-A reveal that, 
although IT for support is adequate, IT for communication and automation are not. With 
detailed knowledge of the process, one can imderstand this diagnosis clearly. This means 
that although adequate IT support is available, it is not paying dividends in terms of 
improvements in process performance. This suggests that the process was never 
engineered, and clearly illustrates Hammer's point that IT alone will not improve process 
performance. The use of information technology enablers such as form tools, word 
processors, spreadsheet applications and others must be integrated into a comprehensive 
process redesign plan. Conventional wisdom in the reengineering profession suggests 
that IT capabilities should not be considered until after the process is designed. However, 
Davenport and Short (1990) suggest that an awareness of IT capabilities should influence 
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the process design. "The role of IT in a process should be considered in the early stages 
of its design." [Davenport and Short, 1990] 

The inadequacies in IT-C are attributed to the lack of electronic communication 
between the PAC and the finance office. Furthermore, lacking IT-A to fully automate 
simple manual routine tasks presents a significant shortcoming. Even complex tasks 
requiring (finance) experts can be automated using expert systems and decision support 
systems with technology commercially available today. Although new technology may 
require a substantial investment of money and training time, the long-term benefits of 
reduced cycle time and reduced cost may outweigh the initial investment. 

C. UNITED STATES COAST GUARD MILITARY DOCUMENT PROCESS 
This section describes the "as-is" MPDP for a United States Coast Guard 
Personnel Servicing Records Unit (PERSRU), which provides pay support to sailors 
located within its Area of Responsibility (AOR). Although the process description is that 
of a particular PERSRU, it is typical to most PERSRUs that perform a similar mission. 

1. "AS-IS" Process Description 

The CG's MPDP is very similar to the Army's linear batch process. Documents are 
created by sailors, given to the unit yeoman who couriers the documents to the PERSRU 
office for processing. The PERSRU electronically transmits the processed documents to 
the Human Resource Servicing Center (HRSIC), followed by mailing the hardcopy of 
each document transmitted. A level 1 schema of this process is represented in Figure 7. 
Figures 8 and 9 show the decomposition of the Unit Yeoman process and the PERSRU 
process respectively. 




Figure 7: US Coast Guard level 1 schema of baseline process 
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The detailed process is as follows: A sailor decides he wants to initiate a pay 
change (Typical CG pay transactions are listed in Table 6). The sailor reports to his 
yeoman (Coast Guard's equivalent to a personnel and administrative clerk in the Army) 
to retrieve the necessary forms. In some cases the form(s) can be downloaded from the 
unit database, or the World Wide Web (WWW). The sailor prepares the document and 
returns it to the yeoman. The yeoman reviews the document for completeness and 
correctness and batches it with documents received from other sailors. The yeoman 
couriers the batch of documents to the PERSRU. It should be noted that documents 
prepared by sailors who are at sea have a significantly longer courier time. These 
documents are transported by air and typically take 24 hours to reach the PERSRU. ’ 

A PERSRU yeoman (similar to the Army's receiving clerk) reviews the 
documents submitted by the unit yeoman for completeness and correctness. 




Figure 8 Unit Yeoman Process (decomposition) 



Documents that are not prepared correctly are given back to the unit yeoman. The 
PERSRU yeoman takes the documents, sorts them by type, and codes (keypunches) 
them into the computer. 
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Unlike the Army, the Coast Guard does not have yeomen designated only to 
coding documents. The PERSRU yeoman who receives the document also codes the 
document. At the end of the day, the coder saves the coded transactions onto a floppy 
diskette, makes a hardcopy of the coded transactions and gives the hardcopy, the floppy 
diskette, and the document to the reviewer (similar to the Army's auditor). The reviewer 
ensures that the transactions are coded correctly. The reviewer, who is also the 
uploader, transmits the coded transactions to HRSIC to process against the sailor's 
MMPA. The decomposition of the PERSRU office process is shown in Figure 9. This 
process is slightly different from the Army, where the auditor and uploader are different 
people. If the transactions are without error, the changes are processed against the 
sailor's MMPA at HRSIC. If the uploaded transactions have any errors, they are 
rejected, reworked and resubmitted. 




Figure 9 PERSRU Office Process (decomposition) 



2. Simulation Results of the " AS-IS" Process - U.S. Coast Guard 
The authors simulate the “as-is” process of the CG’s MPDP system using 
EXTEND + BPR. Once the model is created, a simulation run produces the outputs for 
the CG’s yeoman transaction process and PERSRU's transaction process shown in Table 
10 . 



37 



Table 10 Simulation Output Results - U.S. Coast Guard 



Measurement 


“As-Is” Model Average Values 


Unit Yeoman Transaction Time 




Average Cycle Time per document 


2. 1 9 hours 


Cost per unit Yeoman 


$50 per day/ $ 1 500 per month 


Productivity of Yeoman per day 


7 documents 


Utilization 


60% 


PERSRU Transaction Processing 




Average cycle Time per document 


17.25 min 


Cost of PERSRU Yeoman 


$164 per day/ $4920 per month 


Productivity of PERSRU Yeoman Per day 


1 1 5 documents 


Utilization 


98% 



The unit yeoman transaction process represents the beginning of the MPDP and is 
the starting point as depicted in above in Figure 7. In order to get measurements of 
important factors like cycle time, productivity, and utilization cost reflecting the day to 
day transactions and processes, we use the input variables in Table 5. Cycle time, 
productivity, utilization, and cost are defined in Chapter III, Section B, Subsection 2. 

One of the most important factors to measure and improve in BPR is cycle time. 
For the unit yeoman, cycle time represents the time it takes a unit yeoman to receive a 
pay document from a sailor, review the document for correctness, prepare a transmittal 
letter, and transport the document to the PERSRU. Figure 1 0 shows that average cycle 
time is 1.89 hours and accumulative cycle time is 2.82 hours. Documents placed in the 
unit yeoman's in-box near the end of the day are not processed until the next morning. 




Figure 10 U.S. Coast Guards Unit Yeoman "AS-IS" Results 
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Contributing to the high cycle time is the standard operating procedures followed by the 
yeomen. These procedures require unit yeoman to submit documents to the PERSRU 
between 0800 and 1200 to process for the current day. With only a four hour window to 
process documents the unit yeoman normally concentrates on finance tasks at the 
begiiming of the day. If documents are not submitted in the allotted window they are held 
by the unit yeoman and submitted the next business day. It is important to realize that the 
MPDP process examines only one of many tasks unit yeomen and PERSRU yeomen are 
responsible for. 

Productivity for an eight-hour workday is five pay documents per day. In this case the 
unit yeoman receives five pay-related documents a day. The yeoman’s utilization 
measurement, based on an eight hour workday says that 40% of the unit yeoman's time is 
spent doing other jobs, while 60% of his time is spent processing pay documents. 

The cost for a unit yeoman to review five pay documents, write a transmittal 
letter, transport the TL to the PERSRU, and wait for the PERSRU yeoman to review the 
TL. ABC is used to assign a cost to the service that the yeoman provides. The unit 
yeoman who completes these tasks normally holds a pay rate of E-5 with five years of 
service. The 1999 military pay table was used to calculate the hourly basic pay rate of E- 
5 with five years of service. The model shows a cost of $50.00 per day or $1500 a month 
for the imit yeoman process. The cost can be further aggregated for the number of unit 
yeoman typically serviced by a PERSRU. 

The next process transaction we examine from the level 1 schema in Figure 7 is 
the PERSRU process. Documents arrive every 18 minutes at the PERSRU. The 
PERSRU yeoman takes 10 minutes to review a TL and clear up any obvious mistakes. 
On average a TL contains a batch of five documents. It takes about 20 minutes for a 
PERSRU yeoman to code a batch of documents and for the auditor to review coded 
documents and upload them. Cost, productivity, and utilization are determined using the 
same technique for the unit yeoman. Average cycle time is approximately 3.5 hours (or 
about 43 minutes per batch). The simulation suggests that the PERSRU processes 23 
batches of pay related documents per day. The utilization measurement shows the 
PERSRU is fiilly utilized. The model indicates that 98% of the time is spent processing 
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finance documents and 2% doing other jobs. The model suggest that the cost for the 
PERSRU process is approximately $164 or $4920 per month. 

3. KOPeR Diagnosis of the "AS-IS" Process - U.S. Coast Guard 
Simulating the baseline process using EXTEND provides a graphical depiction of 
the process for applying KOPeR. The graphical depiction of the process is used to 
determine the calculated measures shown in Table 1 1 . 



Table 1 1 Process Measures U.S. Coast Guard ("AS-IS") 



Measure 


Definition 


Calculated Measures 


Process Length 


Number of nodes in 
longest path 


14 


Process Breadth 


Number of distinct paths 


1 


Process Depth 


Number of process levels 


1 


Process Size 


Number of nodes in 
process model 


14 


Process Feedback 


Number of cycles in graph 


5 


Parallelism 


Process Size divided by 
Length 


1.00 


IT Support 


Number of IT-support 
attributes 


7 


IT Communication 


Number of IT- 
communication attributes 


1 


IT Automation 


Number of IT-automation 
attributes 


2 


Process Handoffs 


Number of inter-role edges 


5 



The results for the CG's MPDP baseline obtained from KOPeR are presented in 
Table 12. These measurements are used to compare and evaluate redesign alternatives. 
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Table 12 KOPeR Analysis for US Coast Guard ("AS-IS") 



Measures 


Value 


Pathology 


Parallelism 


1.00 


Sequential Process 


Handoffs Fraction 


.357 


Process Friction 


Feedback Fraction 


.357 


Checking & Complexity 


IT Support Fraction 
(IT-S) 


.5 


IT support looks OK 


IT Communication 
Fraction (IT-C) 


.071 


Inadequate IT communications 


IT Automation 
Fraction (IT-A) 


.143 


IT requires substantial support 



The KOPeR diagnosis indicates that the CG's MPDP suffers from sequential 
process flow, process friction, checking and complexity, inadequate IT communications, 
and an absence of IT automation. These five measures and pathologies suggest serious 
performance implications. 

First, KOPeR evaluates the baseline process as being a sequential process. The 
MPDP sequential process is based on the CG’s history of specialization training, which 
focuses workers on one particular part of the process. This has cycle time implications. 

Second, we find that there is process fnction, which is usually proportional to the 
number of associated handoffs and feedback loops. We also see that the feedback fraction 
is high, which tells us that information is being transferred unnecessarily, and that 
information has to be re-validated while passing through a process. Feedback loops 
normally increase the number of handoffs because the node initiating the feedback must 
be revisited. Thus, one key to reducing the number of handoffs is to reduce the number of 
feedback loops. 

Information technology support (IT-S) is a measurement of the number of process 
tasks that are supported by information technology. It has been stated that simply 
applying information technology to a process without reengineering it is just a quick fix. 
KOPeR diagnoses the CG's MPDP as having adequate IT-S, but these tools are severely 
underused. More robust redesign transformation levers and enablers (i.e., word 
processors, spreadsheets, e-mail etc.) can have a direct effect on process performance. 
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Information technology communication (IT-C) is the number of process 
communications supported by information technology. KOPeR diagnosed this as 
inadequate for the CG's MPDP. There is limited use of IT-C between the unit yeoman, 
PERSRU yeoman, and HRSIC. Encouraging more correspondence via email support and 
the electronic routing of documents should have a positive effect on communication. 

Information technology automation (IT-A) is defined as the number of process 
tasks automated by information technology. KOPeR diagnoses the CG's MPDP as 
needing to automate process activities. Automation saves time and money by replacing 
human labor, but in order for the CG to implement this recommendation a substantial 
infrastructure is first required, particularly in terms of process support and 
communication. The CG should also look towards workflow systems for support and 
communication, as well as intelligent agents. 
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IV. REDESIGN NEW PROCESS 



By the end of the "as-is" analysis in Chapter II, the authors have a thorough 
understanding of the MPDP for the Army and the CG. The "as-is" analysis provides a 
benchmark of the existing process from which comparison of the redesign alternatives are 
made. Although every process instance is unique in some respect, military processes in 
particular share great similarities across various units, commands, services, and even 
allied nations. Such similarities facilitate the wide spread practice of rotating officers to 
new units and assignments every few years. This serves to leverage the power of process 
redesign in the military where service processes are highly similar. What effects redesign 
for one process instance has excellent potential to also improve process performance 
across a myriad of other units, commands, and services. This is certainly the case with 
the U.S. Army and Coast Guard. For this reason, the redesign analysis that follows 
concentrates on a single, common MPDP, the results of which generalize well across like 
processes in the Army and Coast Guard. [DTIC, 1998] Thus, because of the similarity in 
the Army’s and CG's MPDP and to minimize repetition and redundancy, we develop 
redesign alternatives which can easily be applied to either organization, while 
highlighting significant differences in the application of redesign alternatives to the 
different services. 

Continuing with the methodology in Chapter II, the authors identify 
transformation enablers and develop redesign alternatives. Our goal is to develop 
redesign alternatives capable of yielding order of magnitude improvements in process 
performance. 

A. IDENTIFY TRANSFORMATIONS ENABLERS 

We begin by identifying and defining transformation enablers. Table 13 presents 
the class-level taxonomy of redesign transformations, on which we elaborate in this 
section. [Nissen, 1998] The first five transformations are explicitly addressed through 
redesign analysis. The latter two - inter-organizational alliance and management and 
culture - are not considered in present redesign analysis. We feel that by eliminating the 
middlemen there is little need for traditional inter-organizational coordination. The need 
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to reduce cost also poses a need to reduce coordination (cost). The infusion of 
technology in the three alternatives seeks to solve both problems. While we feel that 
finance management and cultural change is necessary to the initial success of each 
alternative, it is not essential to the long term success. The alternatives we present 
eliminate the leadership role and replace it with technology. Initially management will 
play a key role in obsolescing their job as the MPDP transitions from manual to virtual. 
New decisions will focus on technological matters and require fewer managers in the 
loop, as oppose to traditional people matters. 



Table 13 Taxonomy of Redesign Transformations 



Transformation Class 


Sample Instance (Object) 


Workflow reconfiguration 


Process de-linearization 


Information technology 


Shared database system 


Organizational design 


Case manager 


Information availability 


Informate agent 


Human resource 


Team-based compensation 


* Inter-organizational alliance 


Supplier-manager inventory 


* Management & culture 


Employee stock ovraership 



* Transformation classes considered but not used during the redesign step 



'Workflow reconfiguration examines how the steps in a process are performed, but 
not who performs the activities. "Process de-linearization - rearranging serial process 
activities to be performed more in parallel - represents one example of a transformation 
enabler from this class." [Nissen, 1998] An important point to make about workflow is 
that work should be performed where it makes the most sense. In the redesign 
alternatives for the MPDP we suggest that it makes sense to process the work associated 
with a pay transaction at the level of the customer. De-linearization is not an option for 
the MPDP however, because the tasks in the process are sequentially dependent; 
therefore they can not be performed in parallel. 

Information technology (IT) is used to alleviate mundane manual tasks, increase 
workflow efficiencies and communication across functional areas while improving 
process performance. Paper-based forms of communication are examined in the MPDP to 
reduce the number of people-to-people or paper-to-people transactions necessary to 
provide pay service. Some examples of information technology are shared database 
systems, workflow tools, networks (Internet and Intranets), and e-mail. IT has great 
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potential to alter business processes and create new value-added services. [Grenier and 
Metes, 1995] However, incorrect application of IT may only result in process 
improvements rather than breakthroughs. Take, for example, the automation of 
document routing in the travel approval and reimbursement process. Instead of a paper 
being physically sent from approval station to approval station, electronic forms are 
routed through the network. This application of IT simply automates existing processes 
instead of seeking to reengineer the process and take full advantage of the technology. In 
this case, why route the document at all. Why not electronically post the document to an 
approval room (similar to a chat room), for that particular document, where authorized 
approvers can check and handle the approval process. In redesigning the MPDP, 
workflow tools are coupled with Internet technology to develop alternatives and realize 
breakthrough performance improvements. 

Organizational design looks at changing the organization's structure (e.g., from 
hierarchical to flat). Case teams are used as enablers to integrate tasks between 
functional departments. Case teams can help reduce cycle time and cost by eliminating 
unnecessary handoffs. They also enhance job enrichment by increasing team member 
responsibility and allowing the team to take full responsibility of process tasks from start 
to finish. Case teams also allow for the sharing of knowledge and information comprising 
the team with at least one very experienced member. Non-value added activities that 
create delay, excess, or redundancy in a process should be eliminated. Activity titles with 
the following words usually reveal non-value-added activities: move, wait, check, review, 
verify, store, inspect, rework, record, and approve. Any activity that the customer does 
not value should be significantly reduced or eliminated. [Grenier and Metes, 1995] 

As an instance of the organizational design class we add an enabler called 
disintermediation. In the redesign alternatives we apply disintermediation as an enabler. 
Ted Lewis writes in his book, The Friction Free Economy, that value can be added to a 
service by flattening the value chain. "A value chain is flattened by elimination of links. 
In the terminology of the old industrial economy, these links are called middlemen." 
[Lewis, p. 132-133] Lewis says that the elimination of links may be as subtle as 
accessing your bank account from your PC at home, thereby reducing the need for bank 
tellers and possibly banks. The concept of disintermediation says that by replacing the 
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middlemen with technology one can add value to the service while reducing cost and 
cycle time. In the MPDP the middlemen are considered the PAC functions and the 
finance office functions. 

Information availability examines the type, amount and accuracy of information 
available for use by the people who need it. There is a vast amount of information 
contained in finance regulations. This information governs the use, preparation, and 
routing of finance documents. An enabler that would allow one to take advantage of this 
information is a decision support system (DSS). A DSS is capable of distilling vast 
amounts of data into information for customers who require help and answers to common 
finance questions. Technology can impact this transformation class by providing perfect 
information to the customer. Lewis (1997) suggests that middlemen exist because of 
imperfect information. Providing information directly to the customer early in the 
process, supported by an automated DSS, one could possibly prevent unnecessary rework 
and feedback. Customers can have immediate access to needed information, without 
sifting through large regulations previously constrained to the domain of PAC clerks, unit 
yeomen, finance clerks, and PERSRU yeomen. 

Human Resource examines how the new skills are needed to prepare for the new 
jobs created as a function of the redesign project. The MPDP redesign project requires a 
close examination of the core competencies needed by finance officers and enlisted 
personnel. We suggest that finance core competencies must change to support the 
technical environment needed to reduce cycle time and cost. Tracking well-defined 
performance measures will allow managers the ability to quantify results and 
compensation. 

B. GENERATE AND ANALYZE REDESIGN ALTERNATIVES 

Now that transformation enablers are identified, we apply them to each redesign 
alternative. The three redesign alternatives consider a near-term (Alternative One), mid- 
term (Alternative Two), and far-term (Alternative Three) solution. The redesign 
alternatives are analyzed using KOPeR, then simulated using EXTEND + BPR, and 
relative performance comparisons are made against the baseline model. 
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The near-term solution focuses on a redesign alternative, which can yield 
dramatic increases in process performance while requiring minimal organizational 
disruption. This model includes proven technological capabilities currently available 
from commercial sources and easily implemented. Although the near-term solution can 
be implemented with minimal effort, it is still radically different than the baseline model. 
The mid-term solution incorporates the near-term enhancements while increasing the use 
of technology that include Intranet technologies and advanced workflow tools. This 
alternative may require a paradigm shift in the way the services view the role of the 
finance and the PERSRU office. Finally, the far-term solution incorporates alternative 
one and two while taking full advantage of Internet, workflow, and distributed database 
technology. Our redesign solutions are based on the notion that by eliminating the 
middlemen and "squeezing out inefficiencies", in Figure 1 1, as a part of a comprehensive 
redesign approach we can reduce cycle time, cost, and increase customer service. [Lewis, 
p. 133] 




Figure 11. High-level representation of Baseline process 



To better illustrate the three redesign alternatives, we use rich text pictures as 
presented in Figures 13, 14, and 15. The alternatives are discussed in the context of how 
each redesign alternative uses the transformation enablers (e.g., workflow, technology, 
and organizational change) described in Section A above to improve the MPDP process. 
To reduce redundancy, we only highlight differences between each alternative. We begin 
by discussing Alternative One and outline how it differs from the baseline. Then we 
discuss Alternative Two and describe how it improves on Alternative One, which is 
followed by a discussion of Alternative Three improvements. Finally we summarize the 
redesign enhancements for all three alternatives. 
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1. Alternative One 

Alternative One, Figure 13, takes advantage of the following transformation 
enablers: workflow, technology, organizational and information availability. Workflow is 
used to accomplish each task where it makes the most sense, at the customer level. Three 
basic technologies are used to accomplish this: knowledge-based DSS, electronic forms, 
and email. Using a knowledge-based DSS the customer answers questions pertaining to 
the potential transaction. After answering the questions the customer is presented with the 
proper electronic form for the transaction. Electronic forms, such as the ones created by a 
company called FedSoft Corp, based in Fairfax, Virginia, are e-mailed to the finance 
office for processing. In the baseline process the PAC accomplished the tasks of 
determining the customer's needs, assisting with form preparation, and submitting forms 
to finance. The use of workflow and technology enablers eliminates the need for the 
PAC. 

In Alternative One, to facilitate the process in the finance office, organizational 
enablers are used to create two person case teams. Each team has responsibility for 
servicing specific units. Each member on the team is a trained auditor and is empowered 
with the capability to upload documents to DFAS-IN. By aligning each team with 
specific units and providing upload capabilities to each member, one creates job 
enrichment and job satisfaction. Teams receive electronic documents e-mailed from their 
customers, code the transactions, and upload the information to DFAS-IN. Tracking 
measurement metrics such as accuracy statistics on each team can provide information to 
managers about a team's effectiveness and other statistics may help to identify training 
needs. Case teams provide task ownership, attach responsibility to task accomplishment, 
and allow members to see the job through from start to finish. This also creates a sense 
of mission accomplishment. Although the use of technology in this alternative is limited, 
the process is very different from the baseline. Case teams can have positive performance 
effects in terms of cycle time (and often cost), as a single case team eliminates the need 
for handoffs and inter-departmental coordination. [Nissen, 1995] Remember in the 
baseline there are three coders, an auditor, and an uploader. Only the uploader has the 
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capability to upload documents to finance. Also in the baseline coders coded any 
documents available. There is no sense of ownership of the product or task. Through the 
use of the enablers described above the customer now has good information early in the 
process and can perform the transaction himself without assistance from the PAC. This 
alternative is the first step at eliminating the middlemen (PAC and' Finance). 

2. Alternative Two 

Alternative Two, Figure 14, uses the same enablers as one, but enhancement in 
technological enablers provides more functionality for the customer and eliminates the 
finance office case teams in Alternative One. Alternative Two enhances workflow by 
using an Intranet and e-forms with a front-end web page and a backend (local) database 
located at the finance office. The web page incorporates the DSS used in Alternative One 
to help the customer determine the correct form for a particular transaction. The local 
database contains a copy of the soldier's MMPA. Authentication, encryption, and digital 
signatures are used when customers access the web page and log in to conduct a 
transaction. This local database provides each customer with the ability to access his 
account in near real time. When he wants to conduct a transaction, he answers a series of 
questions, an e-form is displayed and only the fields pertaining to the transaction are 
accessible. When the customer submits the form the data are compared against his 
account on the local database. If the transaction is valid, a transaction confirmation is 
returned to the customer. If the transaction is not valid, the system returns a narrative 
reason why the transaction could not be processed at this time. Alternative Two, unlike 
Alternative One, prevents a customer from submitting transactions that are not valid. In 
Alternative One the customer could submit a transaction, and allotment for example, that 
was invalid. An example of an invalid allotment transaction would be a transaction to 
start a duplicate allotment. In Alternative One this could happen and not be noticed until 
it was rejected by DFAS-IN. In Alternative Two the use of a local database provides the 
soldier with near real time feedback. 

In Alternative Two an organizational change at the finance office eliminates case 
teams md replaces them with a front-end finance web page, local database, and a system 
administrator. Currently there are many commercial off the shelf software and hardware 
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products which can be used to create an environment for Alternative Two. Software 
tools such as Cold Fusion can be used to create dynamic web pages and integrate a 
relational backend database. There are also enterprise resource solutions, developed by a 
company called Systems, Applications, and Products in Data Processing (SAP) for 
example, that focus on process integration and functional area integration. These 
products enhance the capability for single source data input. The transaction information 
entered by the customer at the web site never has to be entered again. It is converted into 
the proper format and processed against the local database. The system administrator 
uploads transactions and updates local databases nightly. The use of a local database 
allows the customer the ability to query his transaction history and accoimt status, having 
almost perfect information prior to submitting a transaction. The customers, during in 
processing, would only report to finance to receive their user names and passwords. This 
alternative brings use another step closer to completely eliminating the need for the 
middlemen. 

3. Alternative Three 

Alternative Three, Figure 15, fully incorporates the Internet and distributed 
database technologies to create a virtual finance office. This virtual finance office uses 
web-based tools to process transactions for customers in near real time. This alternative 
requires DFAS-IN to maintain a web page accessible by customers from anywhere in the 
world any time of the day. In Alternative Three customers receive immediate 
notification when the transaction is processed. In this alternative customers access a web 
page with user fnendly menus. Customers can check on the status of their accounts, 
retrieve and print Leave and Earning Statements (LES), and review their transaction 
history files. In the baseline. Alternative One, and Alternative Two, LESs are prepared at 
DFAS-IN, mailed to the finance office and distributed to each unit. For a customer to get 
pay information prior to the end of the month requires a special request. Using e-forms, 
the Internet, enterprise resource planning software solutions, and distributed database 
technology, the information input by the customer goes directly to DFAS-IN without 
human intervention, handoff, feedback loops, or human friction. This alternative results 
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in a new paradigm where the middlemen are replaced by technology. Figure 12 
illustrates the new paradigm. 




Figure 12. High-level Model of Redesign Alternatives (New Paradigm) 



4, System Security Issue 

Technology enablers are the centerpiece of redesign Alternatives Two, and Three. 
While technological enhancement may eliminate the middleman and add value to the 
customer, they also add risk to the process. Sending privacy information such as names 
with social security numbers over electronic medium has always been a concern for the 
military services. Incorporating electronic forms into workflow will require the use of 
digital signatures and data encryption to ensure privacy, integrity, and authentication of 
the customer. The Department of Defense (DOD) and Netscape are addressing security 
concerns. Last year DOD signed a deal with Netscape to provide a public key 
inffastructxue. Because Netscape clients and servers support both FIPS-1 and 
FORTEZZA security standards, new DOD systems will be able to secure various levels 
of information, from basic e-mail messages to top-secret information on troop movement 
and battle strategy. [Hayes, 1998] Security technology must be incorporated into each 
redesign alternative. 

5. Summary 

Alternative One presents significant enhancements over the baseline using several 
transformation enablers. Alternatives Two and Three eliminate the PAC and finance 
office tasks. Using the concept of disintermediation these alternatives eliminate the 
middlemen using technology to accomplish tasks previously done by humans. Expert 
systems and decision support systems replace expert people. The tasks preformed by the 
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PAC (determining need, selecting document(s), and assisting with document preparation) 
and the finance office (coding documents) is done at the customer level assisted by 
technology (soldier or sailor). The concept is no different than on-line banking. Thus, 
moving the task closer to the source (the customer) will shorten the value chain, reducing 
cost and cycle time while improving the customer service. 

Time consuming and costly reworks for incorrect documents will become 
obsolete. Smart (expert) systems will ensure that documents are correct or they will not 
get submitted. Replacing the middlemen in this process is simplified by the standardized 
way the MPDP is designed. There are very few complex decisions made in this process. 
Expert information (rules for entitlements and preparation of forms) is found in the 
Department of Defense Financial Management Regulation (DODFMR). The DSS in each 
alternative captures complex hxunan knowledge about finance topics on a computer. The 
essence is in the interrelationship among the various items of information in so-called 
knowledge bases or finance manuals. This relationship is expressed as "if... then..." type 
of rules. The logical manipulation of logical operations is a somewhat primitive imitation 
of human thought processes, but it is well established and effective nonetheless. 

By removing non-value added tasks one can eliminate the costs incurred from 
those tasks. As Lewis (1998) describes in the Friction Free Economy, hy infusing 
technology and eliminating the middlemen one can increase the value added to the 
customer by making pay transactions more timely and less costly. Once 

disintermediation is applied, shortening the value chain is a natural outgrowth. The 
hierarchical structure supporting this process is reduced to the customer (soldier or sailor) 
and the supplier (DFAS or HRSIC) as shown in Figure 15. Disintermediation 
incorporated with a comprehensive approach to process redesign can dramatically 
improve process performance by eliminating non-value added tasks. 
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Figure 13. Rich Text Picture Alternative One 
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Alternative Two 







Fort Anywhere 




Figure 14. Rich Text Picture Alternative Two 
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ALTERNATIVE THREE 
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Figure 15, Rich Text Picture Alternative Three 
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C. SIMULATION RESULTS OF REDESIGN ALTERNATIVES 

When simulating the redesign alternatives we use the input values from Table 4. 
Each alternative assumes some delays, not calculated in this thesis, associated with 
network throughput and computer processing. We assume these delays are negligible 
when the network is operating properly and that they will not affect cycle time. Results 
are summarized in table 14. 

The simulation results for Alternative One indicate an average cycle of nine 
minutes per document. Recall that the cycle time per document in the baseline process is 
1.36 hours for the PAC. Using electronic documents and email in Alternative One we 
have eliminated the PAC function and effectively eliminated the associated cycle time. 
This represents a 100% improvement over the PAC process in each redesign alternative. 
The average cycle time for Alternative Two and Three can not be adequately measured, 
because it is dependent on the communication architecture and the latency associated 
with network throughput. But without human (middlemen) intervention, cycle time for 
this process step effectively approaches zero. Recall the baseline model of both the 
Army and the CG where the PAC clerk/unit yeoman only had a three or four hour 
window in the morning to get documents to finance to be processed for that business day. 
Each redesign alternative allows document submission on a 24-hour basis by the 
customer. 

Each alternative introduces technological enhancements. Alternative One's 
introduction of workflow tools eliminates the labor cost and cycle time associated with 
the PAC process. The cost of the baseline process based on an eight-hour workday is 
approximately $1 1,880 per month. This amount is the aggregate cost of the PAC process 
and the finance process as shown in Table 7, Chapter III. Using these values one can see 
that Alternative One yields 47% savings in labor cost over the baseline. 

In Alternative Two we calculate labor cost for a system administrator to maintain 
a local database and a web page for the finance office. We propose that the administrator 
be a military officer (or civilian equivalent) with a graduate education, at the rank of 
0-3/GS-12 (with 6 years) and with some finance experience. Using the 1999 military 
pay compensation table, we determine a cost of approximately $4,577 per month for an 
administrator. In Alternative Three we add the cost of one web master to manage the 
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web page at DFAS-IN. DFAS-IN currently has system administrators who manage the 
database containing the MMPAs. We assume based on current service (DFAS 
Homepage) provided by DFAS that the communication and software infrastructure to 
facilitate this redesign alternative is minimal. Alternative Two and Three eliminate the 
cost associated with labor for the PAC process and the finance process by replacing them 
(the middlemen) with technology and can potentially yield a 61% savings over the 
baseline. 

Although the initial overhead cost associated with software and hardware 
upgrades and training can be substantial, the automation infrastructure in most finance 
offices can facilitate easy migration from current systems to web based distributed 
network technology with minimal upgrades. This comparison illustrates that eliminating 
the middlemen in MPDP will result in significant savings in the cost of direct labor while 
decreasing document cycle time and increasing customer satisfaction. 



Table 14 Extend Output Results of Redesign Alternatives 



Measures 


Baseline 


Alternative 

One 


Alternative 

Two 


Alternative 

Three 


Average Cycle Time 
per document 


Ihr 42min 


9 minutes 


Effectively zero 


Effectively zero 


Cost of labor per 
month 


$11,880 


$6263 


$4,577 * 


$4577 ♦ 



*Not calculated using EXTEND 

D. COMPARE REDESIGN ALTERNATIVES TO BASELINE PROCESS 



KOPeR analyses of each alternative indicate a sequential process. However 
workflow enhancements have decreased the number of handoffs from .357 to 0.00 
resulting in a 100% decrease over the baseline, for the three alternatives. Alternative One 
uses a simple DSS, electronic forms, and e-mail which is practical and easily 
implemented. This simple infusion of technology provides dramatic improvements over 
the baseline process. Recall that Alternative One uses technology to eliminate the PAC 
function, but maintains the finance office and reorganizes it into case teams. Alternative 
One does not allow the customer to verify the validity of his transaction prior to 
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submission. Therefore it is possible that the case team may have to send the document 
back to the customer because the transaction requested is invalid (i.e., trying to stop and 
allotment that doesn’t exist). Consequently there is a limited decrease of 7% in the 
feedback fraction. This is remedied in Alternative Two and Three by providing web 
interface to a local database or directly to DFAS-IN respectively. These alternatives 
result in a 100% decrease in feedback friction over the baseline. This is due in large part 
to the workflow tools and web database interface technology that allows almost real time 
access to the customer's account. The three alternatives indicate a dramatic improvement, 
in information technology support, communication, and automation measures, over the 
baseline. Using KOPeR, comparative measures for each redesign alternative are 
presented in Table 15. 



Table 15 KOPeR Com] 


parative Measures 


Measure 


Baseline 

Army 


Alternative 

One 


Alternative 

Two 


Alternative 

Three 


Process Length 


12 


3 


o 


1 


Process Handoffs 


5 


0 


0 


0 


Process Size 


14 


3 


3 


1 


Process Feedback 


5 


1 


0 


0 


IT Support 


7 


3 


:> 


2 


IT Communication 


1 


3 


3 


2 


IT Automation 


2 


3 


o 

J 


2 












Parallelism 


1.167 


1.00 


1.00 


1.00 


Handoffs Fraction 


0.357 


0.0 


0.0 


0.0 


Feedback Fraction 


0.357 


0.333 


0.0 


0.0 


IT Support Fraction 


0.5 


1.00 


1.00 


2.00 


IT Communication 
Fraction 


0.071 


1.00 


1.00 


2.00 


IT Automation 
Fraction 


0.143 


1.00 


1.00 


2.00 



58 



V. 



SUMMARY, CONCLUSIONS, AND FUTURE RESEARCH 



A. SUMMARY 

This thesis examined how redesigning the Army and CG's MPDP could 
dramatically improve cost and document cycle time. Chapter II presented background 
information on the evolution of the Military Pay System and Business Process 
Reengineering. Chapter III discussed the tools used to analyze and redesign the Military 
Pay Document Process. It also provided simulation results as well as KOPeR diagnoses 
of the processes. Chapter IV examined redesign alternatives which dramatically 
improved cost and cycle time. 

B. CONCLUSIONS 

The KOPeR analysis of the "as-is" process indicates that the MPDP suffers from 
major pathology faults. These pathologies suggest serious performance implications. 
KOPeR shows that the baseline process is nearly sequential, and highly departmentalized 
with excessive rechecks. Measurement values for IT-S, IT-C, and IT-A revealed that, 
although IT-S is adequate, IT-C and IT-A are not. This indicates that some IT support is 
available, but is not paying dividends in terms of improved process performance. 

Therefore each redesign alternative presented in this thesis enhances these 
shortcomings by eliminating non-value added tasks and combining tasks. Each suggested 
alternative yields an increase in process performance over the baseline. Alternative One 
reduces labor cost by 47% and cycle time by 90% (from 1.5 hours to 9 minutes per 
document). Alternatives Two and Three reduce labor cost by 61%, as a result of 
eliminating the middlemen, while effectively decreasing the cycle time to zero using 
technology to shorten the value chain between the customer (soldiers or sailors) and the 
supplier (DFAS or HRSIC). 

In each redesign alternative, IT does not simply automate a flawed process, but it 
is used as an enabler to yield dramatic process performance improvements over the 
baseline process. We took a critical look at the tasks and processes associated with the 
MPDP, and asked the questions "Why are we doing it this way?" and "Can it be done 
better?" We concluded that by reengineering the MPDP to eliminate the middlemen and 
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radically changing the process, dramatic improvements in process performance could be 
realized. However, continued research into technology cost, training cost, new man nin g 
numbers, and implementation planning is necessary to realize the true benefit of these 
redesign alternatives. 

C. RECOMMENDATIONS 

The authors recommend that the Army and Coast Guard use each alternative as a 
building block, starting with Alternative One and incrementally increasing functionality 
to obtain the ultimate goal of the virtual finance office as illustrated in Chapter IV, Figure 
15. An incremental development process is useful in systems engineering when all 
requirements are not known up front. Once Alternative One is deployed, there will be 
suggestions from customers and new requires that can improve the MPDP process. 
These suggestions can be implemented in Alternative Two and Three if necessary. The 
incremental approach allows users and customers the ability to take an active role in the 
development of a virtual MPDP. 

The transition from the current MPDP to Alternative One may be easier for the 
Coast Guard than for the Army. The Coast Guard's finance office currently, as illustrated 
in Chapter IV, Figure 13, uses case teams when processing documents at the finance 
office. These teams are already aligned with specific units. The Army, on the other hand, 
uses individual coders who have no association or direct relationship with particular 
units. Implementing the first alternative will require an adjustment period for the Army 
but can be accomplished with minimal impact on current operating procedure while 
making dramatic improvements in process performance. Once Alternative One is 
implemented and proven successful. Alternatives Two and Three are simply functional 
improvements to the first alternative. 

The key to the incremental approach is to establish a time line for completing 
each alternative upgrade. Sticking to this time line will require a dedicated team 
throughout the planning and implementation phase of the redesign project. 
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D. TOPICS FOR FUTURE RESEARCH 



The information presented has the potential to dramatically improve the MPDP 
using technology like e-forms, intranets, distributed database technology, DSS and expert 
systems. The authors recommend four major fields of study for future research before 
implementing any of the alternatives presented in Chapter IV. These areas are not 
sufficiently addressed in this thesis due to time and scope limitations. 

1. Technology Cost 

Technology cost of the alternatives suggested in Chapter IV is an issue that 
should be addressed. Consider possible upgrades to the communication infrastructure to 
create a larger bandwidth capability for transmitting documents and information faster 
and the cost associated with software and hardware upgrades. Addressing the cost for 
hardware and software upgrades, Gary Eldridge states that "A self examination should be 
done that looks at six aspects of IT operations: employees, internal operations, financial, 
innovation and learning, customer value and the value of IT investment." It is imperative 
that the Army and Coast Guard evaluate their current IT technology and then research 
what the cost per unit for each alternative will be to efficiently implement the Virtual 
Finance Office. 

2. Security Issues 

Security will be a major issue in the implementation of each alternative leading up 
to the Virtual Finance Office. Different technology like data encryption and digital 
signatures must be looked at in an effort to securely transmit privacy information across 
an electronic medium such as the Internet. DOD and Netscape's deal to provide a public 
key infrastructure, which provides each military user with a software identification card - 
complete vvith user name and access privileges will go a long way in the evolution from 
the current MPDP to a virtual finance office. The result of the security measures taken 
by DOD and Netscape will allow users to access a range of enterprise-wide applications 
and information while eliminating the need for traditional DOD stovepipe 
communication architecture. John Menkart, the director of federal sales for Netscape 
Government Group, said in a recent article in DoDIT that "Once the system is fully in 
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place DOD will be able to expose even the most mission critical [information] over the 
Internet and still assure that only people that have permission to access it will be doing 
so". [Hayes, 1998] According to Hayes, the majority of everyday business processes will 
be automated and web-enabled. These processes include but are not limited to product 
ordering and delivery, travel voucher settlement, accounting, finance transactions, and 
official communications. The bottom line, says Menkart, is that the military will be able 
to take the best possible advantage of its system to get and transmit information between 
customers (soldiers and sailors) and suppliers with an extremely high degree of security. 

3. Training Cost 

Another major stumbling block for projects, which involve new technology, is the 
user's ability to effectively utilize the product. Infusing new technology will present some 
training challenges. Soldiers and sailors will require training on the use of electronic 
forms and digital signatures while finance personnel will need training on workflow 
tools, web technology, and database maintenance. The cost of training and maintenance 
represents a major part of the life cycle cost of most projects. Therefore the use of 
Commercial off the Shelf (COTS) solution are critical. COTS equipment can present 
users with common tools which they currently use; therefore users require less training to 
become proficient. The use of COTS equipment allows one to take advantage of the 
research and development dollars of the commercial world and can help limit 
maintenance cost. If users aren't properly trained the project is destined for failure. 
Secure funding for adequate training is essential prior to beginning the redesign project. 

4. New Manning Numbers 

The Army and Coast Guard will need to examine new manning numbers for their 
financial communities. Bitzer suggests that improved worker productivity, electronic 
communications, and the automation of work routing, tracking and completion result can 
reduced manpower requirements. Extensive realignment of both organizations along with 
the implementation of new rules and regulations will be needed in each redesign effort. 
Dr. Sharon Caudle notes that many successful government organizations are adjusting 
their organizational structures and reporting relationships to better support process 
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redesign initiatives. However, major change will not happen without top management 
commitment and support. This redesign project will require the senior leaders in both 
services' financial communities to become intimately involved. 

Currently the Army uses a 19 plus person detachment to provide pay support to 
approximately 6000 soldiers. The primary responsibility of this detachment, as described 
in Chapter III, is to provide pay support using the MPDP. By implementing the 
alternative suggested in this thesis we propose that a 19 plus person detachment in its 
current capacity is no longer needed. A smaller more dynamic organization can result 
from the suggested redesign alternatives. Such a major paradigm shift promises to be a 
bit of a culture shock for people interested in maintaining their "rice bowl". But the 
benefits, in term of ccist saving, cycle time, and customer service, that come from 
eliminating non value added tasks easily out weigh the temporary adjustment difficulties. 
The CG's organizational structure is similar and will face similar challenges. 

5. Implementation Plan 

A true implementation plan for any of the alternatives listed in Chapter IV must, 
consider the technology cost, training cost, and manning changes. The authors visualize 
a seven-phase approach for the implementation of the new MPDP process. The seven 
phases of the implementation plan would include marketing, contracting, prototyping, 
installation, testing, training, and the rollout of the new system. These seven phases, we 
believe, are not mutually exclusive and some may overlap each other. Some of these 
phases will be ongoing throughout the project. 

E. FINAL THOUGHT 

This is a quote taken from an executive summary. It expresses the need to 
reengineer processes and eliminate non-value-added tasks, rules, and regulations to 
increase quality and reduce cost in the federal government. 

About 1 0 years ago, two foresters returned from a hard day in the 
field to make plans for the coming week. Searching for a detail of agency 
policy, they found themselves overwhelmed by voluminous editions of 
policy manuals, reports, and binders filled with thousands of directives. 
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One forester recalled the very first Forest Service manual- -small enough 
to fit into every ranger's shirt pocket, yet containing everything foresters 
needed to know to do their jobs. 

'Why is it that when we have a problem,' the other forester asked, 

'the solution is always to add something— a report, a system, a policy— but 
never take something away?' 

The first replied: 'What if ... we could just start over?' [Executive 
Summary, 1993] 

Reducing cost and improving customer service in the government will require a 
systematic approach to process redesign with a focus on dramatic change. The 
alternatives in this thesis represent dramatic change, capable of increasing process 
performance and improving customer service. The focus is to eliminate non- value added 
processes through a systematic redesign approach. Using this systematic approach, 
redesign alternatives are developed for the MPDP, which if implemented can result in the 
reduction of value chains, lower cost, shorter document cycle time, and an increase in the 
quality of customer service. 
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